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Abstract 

Formal models, core calculi, and type systems, are important tools 
for rigorously stating the more subtle details of a language, as well as 
characterizing and studying its features and the correctness properties 
of its programs. In this paper we present FAAL (FEATHERWEIGHT 
AGENT AND ARTIFACT LANGUAGE), a formal calculus modelling the 
agent and artifact program abstractions provided by the sIMPpA agent 
framework. The formalisation is largely inspired by FEATHERWEIGHT 
JAVA. It is based on reduction rules applied in certain evaluation 
contexts, properly adapted to the concurrency nature of sumPA. On 
top of this calculus we introduce a standard type system and prove 
its soundness, so as to guarantee that the execution of a well-typed 
program does not get stuck. Namely, all primitive mechanisms of agents 
(activity execution), artifacts (field/property access and step execution), 
and their interaction (observation and invocation) are guaranteed to 
be used in a way that is structurally compliant with the corresponding 
definitions: hence, there will not be run-time errors due to FAAL 
distinctive primitives. 
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1 Introduction 


Concurrency is gaining momentum in the development of software sys- 
tems, given the widespread diffusion of multi-core architectures and the 
Internet. As nicely put forward by Sutter and Larus in [58]: “the free 
lunch is over”, which means that the capability of writing well-engineered 
concurrent programs — efficiently and effectively exploiting the available 
hardware parallel features — is nowadays a requirement of any mainstream 
language for programming-in-the-large, such as current OO programming 
languages. As such, it becomes more and more important to enhance pro- 
gramming languages with proper high-level abstractions that can “help build 
concurrent programs, just as object-oriented abstractions help build large 
component-based programs” [58]. 

From that perspective, a large amount of proposals have been developed 
in the literature since the 80’s, many extending existing sequential program- 
ming paradigms with concurrency features, such as the case of object-oriented 
concurrent programming approaches [{10, 63, 3]. Among the others, two main 
prominent families of approaches are actors [2] and agents [37]. The actor 
computing model is the reference model of several concurrent programming 
languages and frameworks [39, 40], including Erlang [4], Scala [26], and Ac- 
torFoundry [42]. An actor-based program is defined by a set of autonomous 
active entities that communicate solely by asynchronous message passing. 
On the other hand, agents and multi-agent systems — having their roots in 
the context of Distributed Artificial Intelligence [61, 54] — are nowadays a 
main paradigm for engineering complex software systems exhibiting features 
of concurrency, distribution/decentralisation, autonomy, and flexibility [37]. 
They gave rise to a number of agent oriented programming languages and 
frameworks—surveyed in [8, 7]. Similarly to actors, agents are active entities 
communicating by asynchronous message passing. Differently from actors, 
in agent systems an explicit notion of environment is considered that defines 
agent situatedness: agents are reactive systems that continuously perceive 
their environment and autonomously decide which actions to perform, ac- 
cording to their designed objective [60]. Then, the environment can be 
exploited also as a first-class abstraction to realise indirect /mediated forms 
of communication besides message passing [59]. 

Independently of the abstractions we use, a main problem with the 
engineering of concurrent programs lays in the difficulty of assessing their 
correctness. Formal models based on core calculi and associated type system 
are a widely accepted and standard approach for rigorously stating the 
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more subtle details of a programming language, characterizing and studying 
its features and the correctness properties of its programs. A prominent 
example for this approach is rooted in the FEATHERWEIGHT JAVA calculus 
(FJ) [34], which has being used as the basis for studying the properties of a 
number of extensions of OO languages including sophisticated type systems 
[35]. Besides the formalisation of sequential programming languages, core 
calculi can be valuable tools also for rigorously studying concurrency models, 
concurrent programming languages, or programming languages providing 
some support for concurrent programming. 


Therefore, along with the design of new abstractions, a main research 
issue in concurrency programming is the definition of proper formal mod- 
els, calculi, and type systems, analogously to the sequential case. The 
main examples in this direction are CAP [12], a process calculus based on 
the actor model, Honda and Tokoro’s object calculus with asynchronous 
communication [31], and the join calculus [24]. 


The same situation does not hold for agent programming languages, 
which are the focus of this paper. There are many papers on the formal 
semantics of high-level agent programming languages (e.g., [29, 22, 46, 57, 
21]), and in particular on their operational semantics; none of them, however, 
deals with aspects such as typing and type safety. The main reason is 
that most of them are logic-based, and have been introduced for solving 
problems in the Distributed Artificial Intelligence context; hence, existing 
formalisations focussed on aspects related to the underlying logic-based model 
of the languages, in order to rigorously define the reasoning capabilities of 
agents. A prominent example is [43], where the situation calculus is used to 
formally specify the behaviour of cognitive agents. On the other hand, some 
agent-oriented programming frameworks have been proposed as general- 
purpose approaches to develop concurrent and distributed systems, as an 
extension of OOP. Main examples are Jade [5] and sImpA [53]. These 
approaches would clearly benefit from a proper formalisation including a 
type system capturing the essential features of the agent-oriented abstractions 
on which they are based. 


Accordingly, in this paper we introduce a calculus with type system 
called FAAL (FEATHERWEIGHT AGENT AND ARTIFACT LANGUAGE), cap- 
turing the relevant and distinctive features of simPpA and the A&A (Agents 
and Artifacts) conceptual model [47], introduced in the context of Agent 
Oriented Software Engineering. A FAAL program is given by a set of 
autonomous agents that work concurrently inside a shared environment mod- 
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ularised in terms of non-autonomous entities called artifacts. A distinctive 
aspect of this language is that it is largely inspired by FJ (it is based on 
reduction rules applied in certain evaluation contexts), but it also includes a 
number of techniques used in the context of concurrent models like process 
algebras—e.g., the use of parallel composition of components, and synchro- 
nisation of agent-artifact behaviour. A (well-formed) system configuration 
is seen as a parallel composition of agents and artifacts instances (seen as 
independent and asynchronous processes), the former keeping track of a tree 
of activities to be executed in autonomy, the latter holding a set of pending 
operations to be executed in response to agent actions over the artifact. 

On top of this calculus we define a type system that ensures the correct 
evolution of a system, through the standard properties of progress, and 
preservation of well-formed configurations. In particular, the type soundness 
result we prove guarantees that all primitive mechanisms of agents (activity 
execution), artifacts (field/property access and step execution), and their 
interaction (observation and invocation) are used in a way that is structurally 
compliant with the corresponding definitions. As in most strongly type 
languages, this helps the programmer in writing provenly correct programs 
in a modular way — a rather necessary mean for building complex applications 
— and paves the way for a more extensive behavioural analysis. 


Organisation of the paper Section 2 introduces the basic concepts 
underlying FAAL — and stmpA — programming model. Section 3 presents 
the (typed) syntax, and the operational semantics of the FAAL language. In 
Section 4 we state the theorems related to type soundness. Section 5 revises 
the related papers and Section 6 outlines possible directions for further work. 
The appendix contains the proofs of the theorems of Section 4. 


2 FAAL Agent-Oriented Abstractions and Type 
System: An Informal Overview 


This section provides a brief informal description of the basic abstractions 
on which the FAAL calculus is based. The interested reader can find a more 
detailed account of the programming model in the context of the SIMPA 
framework [53]. 

A program in FAAL is represented by a (dynamic) set of autonomous 
entities called agents. Agents work concurrently inside a shared environment 
represented by a (dynamic) set of non-autonomous entities called artifacts. 
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Agents and artifacts are the basic high-level and coarse-grained abstractions 
available in the A&A conceptual model, recently introduced in the context 
of agent-oriented programming and software engineering as a novel foun- 
dational approach for modelling and engineering complex software systems 
[47]. Agents are used to model task-oriented components of a system, and 
are autonomous in the sense that they encapsulate the logic and control of 
task execution. Artifacts model instead function-oriented components of 
a system, used by agents for accomplishing their individual and collective 
tasks. 

In the remainder of this section we will introduce the essential elements 
of (i) agents, (ii) artifacts and (iz) their interaction in FAAL by using a 
simple example, given by four kinds of agents (Main, Init, User, Observer) 
and an artifact (Counter). The Main and Init agents set up the system, 
while two User agents and an Observer agents work cooperatively by using 
the shared artifact, respectively by incrementing it (Users) and reacting to 
its changes (Observer). 


Agent Abstraction An agent in FAAL is a stateful entity whose job is 
to pro-actively execute a structured set of activities as specified by the agent 
programmer. Such activities (which may possible be non-terminating) finally 
result in executing sequences of atomically-executed actions: internal actions 
that inspect/change agent state, or external actions by which interaction 
with the agent environment is achieved. Examples of agents with a single 
main activity are given by the Main and Init agent: 


agent Main { 
activity main() { 
spawn Init(make Counter(0)); 
} 
} 


agent Init f{ 
activity main(Counter c) { 
spawn Observer(c) ; 
spawn User(c); 
spawn User(c); 


} 


Built-in actions make and spawn are used create artifacts and to spawn 
agents. The state of an agent is represented by an associative store, called 
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memo-space, which represents the long-term memory where the agent can 
dynamically attach and associatively read/retrieve chunks of information 
called memos. A memo is a tuple, characterised by a label and an ordered 
set of arguments. Besides keeping track of state information, memos are 
useful to coordinate the execution of structured activities, as will be shown 
in the following. 

A basic set of internal actions is available to agents that work with the 
memo-space: +memo is used to create a new memo with a specific label and 
a variable number of arguments, ?memo and -memo to get /remove a memo 
with the specified label. Labels of memos have a type, which constrains the 
type of values used in arguments. 

The computational behaviour of an agent can be defined as a hierarchy 
of activities (corresponding to the execution of some tasks). An example is 
given by the Observer agent: 


agent Observer { 
activity main(Counter c) :agenda ( 
prepare(c) :pre tr 
:pers fls, 
monitoring(c) :pre completed(prepare) 

:pers (not memo(finished) ) 

) {} 

activity prepare(Counter c) { ... } 

activity monitoring(Counter c) { ... } 


Activities can be simple or structured, and are represented by activity 
blocks, providing the name of the activity, parameters, and behaviour speci- 
fication. The behaviour of a simple activity (prepare and monitoring in 
the above example) is composed of a flat sequence of actions (inside curly 
brackets), which specifies a single control flow. 

For structured activities (like main in the above example), an agenda is 
specified, containing a set of sub-activities, called todos. These sub-activities, 
which run concurrently, have to be completed before the activity may start 
the execution of its sequence of actions (inside curly brackets). This leads to 
a hierarchical structure of running activities. 

A todo contains the name of the sub-activity to be executed, a pre- 
condition over the inner state of the agent that must hold for the specified 
sub-activity to start (clause : pre), and a persistence attribute related to the 
sub-activity execution (clause : pers). 
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Preconditions are expressed as a boolean expression over a basic set of 
predefined predicates. Predicates make it possible to specify conditions on 
the current state of the activity agenda, in particular on (i) the state of the 
sub-activitities (if they started, completed, or aborted) and on (ii) the local 
inner state of the agent, that is the memo space. For instance, the predicate 
memo(M) is true if the specified memo M is found in the memo space. In the 
Observer example, in the structured activity main, the activity monitoring 
is executed when the activity prepare completed — completed(A) is a 
built-in predicate which is true is the specified activity A has completed. 

When the precondition of a todo item holds (for an activity in execution 
listing such a todo in the agenda), the todo is removed from the agenda and 
an instance of the sub-activity is created and executed. So, multiple sub- 
activities can be executed concurrently and asynchronously, in the context of 
the same parent activity. Sub-activities execution can be then synchronised 
by properly specifying preconditions in todos, hence in a declarative way. If 
a todo is declared persistent, when the sub-activity is completed the todo is 
re-inserted into the agenda. The persistence attribute can also specify the 
condition under which the activity should persist. For instance, the todo 
item about the monitoring activity is declared persistent until a finished 
memo is found. 

The type system of FAAL, in addition to the standard checks for 
expressions, will also ensure that activities mentioned in todo lists and in 
preconditions/persistence predicates, are those defined for the agent. This is 
the key to guaranteeing that the only form of agent-to-agent interaction is 
via artifacts, as dictated by the A&A conceptual model. 


Artifact Abstraction An artifact is composed of three main parts: (i) 
observable properties, which are attributes that can be observed by agents 
without an explicit agent action towards the artifact; (i) a description of 
the inner non-observable state, composed of set of state variables analogous 
to private instance fields of objects; and (iii) operations, which embody the 
computational behaviour of artifacts. A minimal example of artifact is given 
by the following Counter: 


artifact Counter { 
obsprop int count; 
Counter(int c) { .count = c; } 
operation inc() { .count = .count+1; } 
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This artifact has one observable property (count), no inner state vari- 
able, and one operation (inc) to increment the counter. 

Both state variables and observable properties are declared similarly 
to instance fields in objects; observable properties are prefixed by obsprop 
keyword. In both cases, a dot notation (e.g. .count) is used both for 
l-values and r-values, to syntactically distinguish them from parameters. 
Operations can be defined by method-like blocks, prefixed by the keyword 
operation, specifying the name and parameters of the operation and a 
computational body. It is worth noting that no return parameter is specified, 
since operations in artifacts are not exactly like methods in objects. 

Operations can be either atomic, executed as a single computational 
step, or structured, i.e. composed of multiple atomic operation steps. For 
each operation a guard can be specified (: guard declaration), representing 
the condition that must hold for scheduling the execution of the operation 
code. Structured operations and guards are essential in easily implementing 
coordination artifacts, i.e. artifacts that are designed to mediate agent 
interaction and provide some coordination functionality. A simple example 
is given by a synchronisation barrier artifact: 


artifact Barrier { 
int v; 
Barrier(int n){ .v =n; } 
operation synch() { .v = .v-1; step allSynched() } 
step allSynched() :guard (.v == 0) {} 


This artifact is useful for synchronizing a set of n agents, each executing 
the synch operation as a synchronisation point. The hidden state variable v 
keeps track of the number of agents that executed synch so far. The synch 
operation is composed of two steps: in the first (implicit) one, the internal 
variable is decremented; the second one is executed only when v reached zero, 
meaning that all agents reached the synchronisation point. Other examples 
of components that can be suitably modelled as coordination artifacts are 
bounded buffers, blackboards, communication channels [53). 

To be useful, an artifact should typically provide some level of ob- 
servability. This is achieved both by generating observable events through 
the signal primitive, and by defining observable behaviours. The events 
generated through the signal primitive can be sensed by the agent using 
the artifact — i.e. by the agent which started the operation. An observable 
event is represented by a labelled tuple, whose label represents the kind of 
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the event and the information content. The end of an operation is an observ- 
able behaviour generating the event op_exec_completed, whereas when a 
property changes, an event of type prop_updated is generated (with the new 
value of the property as a content). For instance, in the Counter artifact inc 
operation generates a prop_updated(count, Value) event each time the 
observable property count is updated. These events may be sensed by all 
the agents that are focussing (observing) the artifact (more details below). 

Type checking an artifact is very similar to typechecking for classes, as 
fields and properties are typed. Our type system is nominal (like that of 
Java), so the type of an artifact is the name used in its definition. 


Agent-Artifact Interaction Model We explain the details of agent- 
artifact interactions based on the full program of the example reported in 
Figure 1. 

As already stated, artifact use and observation are the basic form of in- 
teraction between agents and artifacts. The use of an artifact by an agent 
involves two basic aspects: (i) executing operations on the artifact, and 
(ii) perceiving through agent sensors the observable events generated by 
the artifact. In the abstract language presented here, sensors used by an 
agent are declared at the beginning of the agent block (see sensor s in agent 
Observer)—note that each agent instance gets its private instance of the 
sensors. 

In order to trigger operation execution, the use action is provided 
(exemplified in activity usingCount of agent User), specifying the target 
artifact (c), the operation to execute (inc) and optionally the identifier of 
the sensor (s) used to collect observable events generated by the artifact. The 
type system checks that agents invoke only operations that are defined for 
the artifact type, and that sensors are defined for the agent. It is important 
to note that no implicit control coupling exists between an agent and an 
artifact while an operation is executed. 

The sensor that one may provide with the use primitive is associated 
with the activation of the operation, so that a synchronisation may be created 
between the agent and the artifact. During the execution of the operation 
the artifact may perform a signal, which adds to the associated agent 
sensor a perception (represented by a pair of a label and a value) that may 
be sensed by the agent via a sense primitive. The execution of a sense is 
blocked until there is a perception available, in which case it is returned. The 
code of operation inc2 in the Counter artifact shows an example of signal, 
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artifact Counter { 
obsprop int count; 
Counter(int c) { .count = c; } 
operation inc() { 


-count = .count+1; 

+ 

operation inc2() { // variant showing signalling 
-count = .count+1; 
signal (val(.count)); 

3 


} 


agent Main { 
activity main() { spawn Init(make Counter(0)); } 


} 


agent Init { 
activity main(Counter c) { spawn Observer(c); spawn User(c); spawn User(c); } 


} 


agent Observer { 
Sns s; 
activity main(Counter c) :agenda ( 
prepare(c) :pre tr 
:pers fls, 
monitoring(c) :pre completed(prepare) 
:pers (not memo(finished) ) 
DAF 
activity prepare(Counter c) { focus(c,s); } 
activity monitoring(Counter c) { 
sense s :filter prop_updated; 
int value = observe c.count; 
// do something 
if (value >= 100 ){ +memo(finished); } 


} 


agent User { 
Sns s; 
activity main(Counter c) :agenda ( usingCount(c) :pre tr :pers tr ) { } 
activity usingCount(Counter c) { 
use c.inc() :sns .s; 
} 
activity usingCount2(Counter c) { // variant showing sensing 
use c.inc2() :sns .s; 
... // code that does not need the updated counter 
sense .s :filter val; 
... // code that may assume that the counter has been updated 


Figure 1: The complete program including an Observer agent continuously 
observing a Counter Artifact, which is concurrently used by two User agents. 
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occurring each time the counter is updated and using val as label and the 
counter status .count as value. On the other side, if the agent wants to 
know whether the counter has been updated it should specify a sensor along 
with the use primitive, and use a sense when it needs the value, as shown 
in usingCount2 activity of User agent. Note that a filter val is specified at 
sensing time, to select only the events labelled val—siImMPA provides general 
filters based on regular-expression patterns, matched over the event type 
(a string), while in FAAL we model a simple matching on label names. In 
general, sensing signals is the mechanism by which agents can get output 
results that could be possibly generated by the operation execution. 


Besides sensing events generated when explicitly using an artifact, a 
support for continuous observation is provided. If an agent is interested in 
observing every event generated by an artifact — including those generated as 
a result of the interaction with other agents — two actions can be used, focus 
and unfocus. The former is used to start observing the artifact, specifying 
a sensor to be used to collect the events and optionally the filter to define 
the set of events to observe. The latter is used to stop observing the artifact. 
In the example, the Observer agent executes a focus on the artifact in the 
prepare activity. 

In our formalisation we shall model this kind of observation by restricting 
the observation to the completion of operations of an artifact, and the 
updating of its properties. To this end, we used the Observable/Observed 
pattern: agents insert sensors in the run-time artifacts to be observed. These 
sensors are used by the artifact to signal an observable event, and are sensed 
by the observing agent. Our type system ensures that sensors can only be 
defined in agents, and may not be passed as parameters to operations, so 
that artifacts cannot be aware of which sensor they are signalling to. This 
makes it possible to enforce a discipline of programming which is faithful 
to the A&A conceptual model, where artifacts as observable entities are 
not required to keep track of who is observing or using them: this is part of 
the interaction model and the artifact programmer can (and should) design 
artifact structure and behaviour abstracting from such a detail. 


A main objective of FAAL is to have a formal framework to study 
errors of different kinds that can occur when executing SIMPA agent-oriented 
programs, having defined a sound notion of type of agent-oriented abstrac- 
tions. Almost all existing agent programming languages are untyped or 
weakly typed; therefore, many simple but important types of errors are 
discovered only by executing a program [51], at runtime. The same holds 
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also for the simMpA framework, which is based on pure Java types. Then, 
it is not possible — for instance — to detect at compile time if an agent is 
specifying a wrong operation when using an artifact, or if an agent tries to 
sense an event which is never generated by the focused artifact. In FAAL 
these simple errors can be clearly detected statically by having defined a 
suitable type system for agent and artifact abstractions. 


3 FAAL Syntax, Typing and Operational Seman- 
tics 


3.1 Syntax 


The syntax of FAAL (FEATHERWEIGHT AGENT AND ARTIFACT LANGUAGE) 
is presented in Figure 2. 

In presenting the calculus we use a set of conventions for names: G 
ranges over agent names, A ranges over artifact names, and C denotes the 
types of basic values (including Bool and Unit). For program identifiers: s 
denotes sensor names, 1 labels, f field names, and p property names. Finally 
we will use a for activity names, and o for operations and steps. 

The overbar sequence notation is used according to [34]. For instance: 
“#” denotes the possibly empty sequence “f1,...,£,”, the pair “Ux” stands 
for "Uy i555 Up, Xan “UF stands for “Wy 41s .5U,f.3", The empty 
sequence is denoted by “0”. 

There are very minor differences between the syntax of the calculus and 
that of the language used for the examples, namely, tuples are not first-class 
but are seen as specific kinds of basic values, and specifiers (: agenda, : pers, 
:pre, :guard and :sns) are mandatory instead of optional. 

The expression fail models failures in activities, such as the evaluation 
of ?memo(1) and -memo(1) in an agent in which the memo-space does not have 
a memo with label 1. Note that the types of parameters in artifact operations 
and the type of fields and properties may not be sensors. Moreover, the 
signal expression, signal(1(e)), does not specify a sensor. Therefore, sensors 
may not be explicitly manipulated by artifacts. 

As already hinted in the overview, operations can be either executed as a 
single computational step, or be composed of multiple atomic operation steps. 
Operation steps are implemented by operation-like blocks qualified with step, 
and can be triggered (enabled) by means of the next primitive specifying 
the name of the step to be enabled next and possibly its parameters. 
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Uo n= Gl/A|c Agent / artifact / basic value types 
T s:= U| Sns Types 
GD ::= agent G{Sns 8; Act } Agent (class) definition 
Act w= activity a(T x) :agenda(SubAct) {e; } Activity definition 
SubAct ::= a(€) :perse :pree sub-activity definition 
AD s:= artifact A {Uf; Up; Op Step } Artifact (class) definition 
Op ::= operation o (UX) :guard e fe; } Operation definition 
Step s= stepo(Ux) :guarde {e;} Step definition 
eon= x|c Expressions: variable / basic value 
spawnG(é@) | make A(é) agent and artifact instance creation 

ese sequential composition 

f£|f=e artifact-field access / update 

_p| p=e artifact-property access / update 

next o(é) | signal(1(e)) next step / event generation 

Ss sensor 

use e.0(@) :sns e operation use 

sense e :filter 1 event sensing 

focus(e,e) | unfocus(e, e) focus / unfocus 

observe e.p get property value 

?memo(1) | -memo(1) | +memo(1(e)) memo operations 

memo(1) memo predicate 

started(a) | completed(a) | failed(a) activity state predicates 

fail activity error 


Figure 2: Syntax 


3.2. Typing 


The FAAL calculus is equipped with a small-step operational semantics (cf. 
Section 3.3). This section presents the type system of FAAL. The main 
property enforced by the type system is the fact that the execution of a 
well-typed program does not get stuck: that is, if a running agent has some 
ongoing activity or an artifact has some operation to perform, then there 
is some rule that can be applied, hence execution will not lead to run-time 
errors (cf. Section 4). That is the standard type soundness property of 
statically typed languages. 

An agent table GT and an artifact table AT map agent and artifact 
names to agent and class definitions. Following FJ [34], in presenting the 
type system and the operational semantics we assume fixed, global tables 
GT and AT. A program is a pair (GT, AT). We assume that these tables are 
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artifact C { 
obsprop int c; 


operation inc() :guard tr { .c = .ct1; } 
+ 
agent U { 
Sns s; 
activity main(Counter c) :agenda ( usC(c) :pre tr :pers tr ) { } 
activity usC(Counter c) :agenda() { use c.inc() :sns .s; } 


Figure 3: Simplified versions of the artifact Counter and the agent User (cf. 
Figure 1) 


well-formed, i.e., they contain precisely one entry for each agent /artifact 
mentioned in the program. 

While presenting the type system, we will use the simplified versions of 
the artifact Counter and the agent User given in Figure 3 (cf. Figure 1) to 
illustrate some of the typing rules. 

The typing rules for expressions, activity and agent declarations, opera- 
tion/step and artifact declarations are given in Figure 4, 5 and 6, respectively. 
A type environment, I’, is a finite mapping from variables to types, written 
[xT]. 


The typing judgements are as follows. 


e |’ e:TIN XJ meaning that, under the assumptions in I, the expres- 
sion e has type T in the context of the artifact or agent X. The top of 
Figure 4 contains the rules for expressions that may occur in any con- 
text (artifact or agent). In rule [Tval], the function typeOf returns the 
type of a basic value (mapping tr and fls to Bool, and unit to Unit). 
The most interesting rules are: [TnewA], which ensures that when 
an artifact is created all its fields and properties are initialised with 
values of the appropriate type; and [TnewG], which ensures that when 
an agent is created the parameters of the activity main are initialised 
with values of the appropriate type. 


The middle of Figure 4 contains the rules for expressions that may 
occur inside artifacts only. The most interesting rules are: [Tnext], 
which ensures that when an operation step in invoked all the required 
parameters are supplied with the right type; and [Tsend], which ensures 
that when a perception is added to a sensor the type of the expression 
e is that of the values that may be associated with the label 1, which is 
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Expressions that may occur in agent activities or artifact operations/steps: 


[TF e,:Ti INX 
[TE x:T(x) NX [Tvar] [bt c:typeOf(c) InxX = [Tval] Tk eg: To INX 


T+ e1;e2 : To INX 


UfeaA Tke:Umnx activity main (Tx)---€G 
Upea The’:U wx (TnewA] Thke:TINX 
T} make A(é,@’): AINX 


[TnewG] 
[+ spawn G(é) : GIN X 


Expressions that may occur in artifact operations/steps only: 


UfEA £:¢CFf UfeEA £;C€f Thre:U; INA 


[TfieldR] [Thiel W] 
[+ .£;:U; INA [TF .f;=e:U; INA 
UpeaA prep UpeaA prep Tre:UINA 
— rp] [Cpr] 
[TF .pi:U; INA TRF.pj=e:T, INA 
Tre:uina The:UINA typeOfLab(1) =U 
step o(U x)--- EA [Tnext] [Tsend] 
[next 0(6): AINA ['} signal(l(e)):UINA 


Expressions that may occur in agent activities only: 
activity a---€G 


[TstateAct] 


I} started(a) : Bool ING [Th fail: TING [fail] 
I+ completed(a) : Bool IN G 
T 


failed(a) : Bool ING 


SnsS5€G ses [te:Sns ING _ typeO0fLab(1) =U 


———— | ons} [Tperc] 
[TF .s:Sns ING ['} sense e :filter1:UING 
Tke’:AING [Tbe:TING typeOfLab(1) = T 

Le: [Tmm] 
ae oon one [+ ?memo(1) : T ING 
operation o(U X)---EA 
[Tte:UING 


( 
I} -memo(1) : TING 

[Top] [+ +memo(1(e)) : TING 
r ) 


TF use e’.o(é) :sns e: Sns ING - memo(1) : Bool IN G 


TFe’:SnsINnG TkKe:AING TFe’:SnsING [TkKe:AING 
SS _[Tiocus] 9 — 


[Tunfocus] 
I’ focus(e,e’) : Sns ING 


I’ + unfocus(e,e’) : Sns ING 
UpeaA Thre:AING 


———_______——_ [TpropA] 
[+ observe e.p; : Uj; ING 


Figure 4: Typing rules for expressions 
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[x:T]/e:TING  started(a), failed(a), completed(a) are not ine 
(for all 4 € 1..n) 
SubAct; = a;(@’) :pers e; :pre ey 6&',e/,e/’ side effect free 
activity a; (T’ x’)---EG 
[x:Thke’:T inc [x:TlK ef:Bool ING [x:T] e/: Bool ING 
F activity a (T x) :agenda (SubAct, ---SubAct,,){e;} OK ING 


[x:Uj]Fe’:T INA 

[x:U] t+} e:Bool INA e side effect free 
/ operation o(U x) :guarde {e’;} OK INA 
/ step o(U x) :guard e {e’;} OK INA 


Figure 5: Typing rules for activities and operations/steps agents 


F Act OK ING 
activity main (TX) : agenda(SubAct){e; } € Act 
F agent G { Sns 8; Act} OK 


+ Op OK INA 
- Step OK IN A 
F artifact A{U f; V p; Op Step} ok 


Figure 6: Typing rules for agents and artifacts 


specified by the function typeOfLab. Consider, for instance, operation 
inc of artifact C (Figure 3). Since the operation has no parameters, its 
body (.c = .c+1) can be typed under the empty set of assumptions. 
Assume that there are integer constants of type int, and the obvious 
typing rule for the sum of two integer expressions, say |[Tsum]. The 
typing is as follows: 
intc €C 
[TprR] 


F1:int INC [Tval] -.c:int INC 
[Tsum] 


intc €C F.c+i1:int INC 


[TprW] 


F.c=.c+i1:intINC 


The bottom of Figure 4 contains the rules for expressions that may 
occur inside agents only. The most interesting rules are: [Tfail], which 
states that fail may have any type; [Tperc], which states that if an 
agent senses a perception via one of its sensor then the type of the 
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obtained value is the one specified by the label 1 used as filter; and 
[Top], which ensures that when an agent uses an artifact the supplied 
sensor belongs to the agent, the invokes operations is supported by the 
artifact and all the parameters required by the operations are supplied 
with the right type. Consider, for instance, activity usC of agent U 
(Figure 3). Its body (use c.inc() :sns .s) can be typed under the 
type environment T = {c:C}, as follows: 
Sns .s €U 


—_________—_[|Tsns] 
[TFc:UInU [Tvar] [F.s:Sns INU 


operation inc()---€U 


[Top] 
TF use c.inc() :sns .s: Sns INU 

For an activity to be well typed, as shown in Figure 5, the expression (i.e. 
the body), must be well typed, and should not contain the predicates 
started(a), failed(a), and completed(a) that are meant to be just 
in the preconditions and persistence predicates. These predicates 
are used to coordinate the execution of sub-activities. Persistence 
and precondition predicates should be without side effects, that 
is, expressions which are (a boolean combination of) either a basic 
value c, or a parameter activity x, or one of the predicates memo(1), 
completed(a), failed(a), and started(a). The parameters of the 
activity, x, may be used in the body of the activity and also in its 
sub-activities, providing a common state for the sub-activities. For 
instance, the formal parameter c of activity usC of agent U (Figure 3) 
is used in the body of the activity. The activity usC is well typed 
according to the rule at the top of Figure 5 (the typing of the body of 
activity usC has been showed before). The same rule can be used to 
establish that the activity main is well typed (since the body of the 
activity is empty, the first premise can be ignored). 


Type checking of operations, Figure 5, checks that the body of the 
operation is well typed, and that its guard is of type boolean, and 
is side effect free. For an operation this means that the expression 
is (a boolean combination of) either a basic value c, or a parameter 
activity x, or a field access .f, or a property access .p. For instance, 
the operation inc of artifact C (Figure 3) is well typed according to 
the rule at the bottom of Figure 5 (the typing of the body of operation 
inc is shown before). 


” 


-F ... OK| meaning that the agent/artifact “...” is well typed. The 
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associated typing rules are in Figure 6, and just say that all the defined 
activities/operations/steps are well defined. Note that agents must 
contain the activity main. For instance, the rules can be used to 
establish that both the artifact C and the agent U (Figure 3) are well 
typed. 


Definition 1 (Well-typed programs) We write (GT, AT) OK, to be read 
“the program (GT, AT) is well-typed”, to mean that the agents in GT and the 
artifacts in AT are well-typed. 


In the following we always assume that programs are well-typed. 


3.3. Operational Semantics 


The operational semantics is described by means of a set of reduction rules 
that transform sets of instances of agents/artifacts/sensors, each of which 
has a unique identity, provided by a reference. The metavariable 7 ranges 
over references to instance of agents, a over artifacts, o over sensors. 

The order in which the run-time expressions are evaluated inside 
agent /artifact instances is specified by using the standard technique of 
evaluation contexts [62]. 


3.3.1 Run-Time Expressions and Values 


The run-time expressions, the expressions used during evaluation, do not 
contain variables, as variables are dynamically replaced by references, as 
we will see when defining the operational semantics. However, run-time 
expressions may contain references to agents, artifacts, or sensors. Therefore 
run-time expressions are defined by replacing, in the productions of the 
grammar for expression in Figure 2, x with ¢. 

The run-time values, ranged over by v and w, are defined as follows 


That is, a value is either a reference to an agent /artifact /sensor instance or 
a basic value. 

In the rest of the paper we use “expression” to refer to run-time expres- 
sions, whereas we use “user-level expression” to mean that the expression is 
generated by the grammar in Figure 2. 
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3.3.2 Configurations 


Configurations are non-empty sets of sensor, agent, or artifact instances. 
Sensor instances are represented by 


o = (Tvs 


where o is the instance identifier, and 1¥V is the queue of label/value asso- 
ciations representing the events generated (and not yet perceived) on the 
sensor. 

Agent instances are represented by 


p= eR) 


where ¥ is the agent identifier, G is the type of the agent, 1V is the content 
of the memo-space, o is the sequence of references to the instances of the 
sensors that the agent uses perceive, and R is the state of the activity main 
that was started when the agent was created. All the activities that the 
agent will be involved in are subactivities (possibly not direct) of the activity 
main, as we can see from the example in Section 2. The sensor instances in 
@ are in one-to-one correspondence with the sensor variables declared in the 
agent (see the rule at the bottom of Figure 5), and are needed since every 
agent uses its own set of sensor instances. 

An instance of an activity, R, describes a running activity. As explained in 
Section 2, before evaluating the body of an activity we have to complete the 
execution of its sub-activities, so we also represent the state of execution of 
the sub-activities. 


R.#= -a(v)[Sri---Sr,|{e} | failed* 


The name of the activity is a, V are the actual parameters of the current 
activity instance, Sr ,---Sr, is the set of sub-activities running, and e is the 
state of evaluation of the body of the activity. (Note that the evaluation of 
the body starts only when all the sub-activities have been fully evaluated.) 
With failed?* we say that activity a failed. If the evaluation of a sub-activity 
is successful then it is removed from the set Sr, ---Sr,. So when n = 0 the 
evaluation of the body e starts. 
The state of a running sub-activity is represented by: 


Sr s:= a(€)(e1,e2) | R 
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During the evaluation of the precondition and the persistence predicate a 
sub-activity is represented by the term, a(v)(e1,e2) where e; (resp., e2) 
represents the state of evaluation of the persistence (resp., precondition) 
predicate. The persistence predicate is evaluated first and if it evaluates to 
tr, then the evaluation of eg is started. 

In the operational semantics, we will see that when an activity starts 
for the first time, the persistence predicate of all its sub-activities is set to tr 
(rule [SCH]), so that sub-activities are executed at least once (in accordance 
with the truth of their precondition). A subsequent scheduling will depend 
on the truth of the persistence predicate. In case, the evaluation of the 
persistence predicate e; is fls the sub-activity is removed from the set of 
running sub-activities. 

The precondition eg is evaluated only in case the persistence predicate 
e,; = tr. If eg evaluates to tr, the term a(¥)(tr,tr) is replaced with the 
initial state of the evaluation of the activity a with parameters v, which 
is represented by R. Instead, if e2 evaluates to fls the evaluation of the 
precondition of a is rescheduled. 

Artifact instances are represented by 


a = (f =¥,p—w,o,0)---0,)4 


where a is the artifact identifier, A the type of the artifact, the sequence 
of pairs f V associates a value to each field of A, the sequence of pairs pw 
associates a value to each property of A, the sequence o represents the sensors 
that agents focusing on A are using, and 0;, 1 <7 <n, are the operations 
that are in execution. We consider 0; ---0,, a queue with first element 0, and 
last 0,. Artifacts are single threaded and (differently from agents that may 
have more than one activity running at the same time) only the operation 
0,, is in execution at any time. 

A running operation, 0, is defined as follows. 


O s:= (0,0(v)[St;---Stp](e1){e2}) | (0,0[Sti---St,]) p>0,q>1 


The first kind of running operation is an operation that is evaluating its guard 
or its body, whereas the second kind specifies an operation that is evaluating 
the guards of its steps (after having evaluated its body). For a running 
operation 0, o identifies the sensor associated with the operation which was 
specified by the agent containing the use that started the operation, and 
that is used to send events generated during the execution of the operation 
by signal, [St;---St,] is the set of steps generated by the evaluation of the 
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body e2 of the operation. Moreover, ¥ are the actual parameters on which 
the operation was started. 
For the running operation (0, 0(¥)[St,---St,](e1){e2}), if e1 is different 
from tr or fls the operation is evaluating its guard e,;. If ey = fls 
then the operation is dequeued and then enqueued, so that when it will 
be rescheduled it will restart evaluating its guard. If ey = tr then the 
operation is either evaluating its body eg or when eg is a value: if p = 0 
(no steps were generated), then the operation is successfully completed and 
therefore dequeued, otherwise, i.e., (0, o(¥)[St1 ---St,](tr){v}) where p > 1, 
the operation is dequeued and (a, o[St; ---Stp]) is enqueued, so that when 
it will be scheduled the evaluation of the guards of its steps will start. 
Operation steps 

St st olv)e} 


in addition to the guard e, specify the actual parameters of the operation 
step. 


3.3.3. Evaluation Contexts and Redexes 


Evaluations contexts are used for specifying the evaluation order of various 
constructs. In particular, we will use it for expressions, and in this case, as 
Proposition 1 states, they are deterministic. They identify the first redex 
to be reduced. We will also use evaluation contexts later for activities and 
operations. For operations these contexts are again deterministic, whereas 
for activities they are not, since if there are many sub-activities, the choice 
of which one to evaluate first is not fixed. However, once a sub-activity is 
chosen, then the first expression to evaluate is uniquely determined. 


An evaluation context for expressions E is an expression with one hole | ] 
in it. The term Ele] denotes the expression obtained from the context € 
by substituting its hole with the expression e. Let y € {focus, unfocus}. 
Evaluation contexts for expressions are defined as follows 

E := |] | spawnG(v€e) | makeA(vEe) | Ese 
| £=€ | next o(v€e) | signal(1(€)) | p=Eé 
| usee.o(@) :sns€ | use €.0(é) :sns v 
| use v.o(v€é) :sns v 
| +memo(1(€)) | observe €.p 
| | 


pl(E,e) y(v,€) | sense € :filter 1 
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Evaluation contexts for expressions specify the standard call-by-value eval- 
uation, where in general parameters are evaluated left-to-right. Redezes, 
ranged over by rdx, are the elements of the set V¥ = 1, UX U 4x, where: 


A = {spawn G(v),make A(¥),v;e} 
X% = {£,.f =v,.p,.p=v,next o(¥), signal(1(v))} 
Xe {.s,use v.o(¥) :sns v, sense v :filter 1, 


?memo(1), -memo(1), +memo(1(v)),memo(1), 
focus(v, v), unfocus(v, v), observe v.p, 
completed(a), failed(a), fail} 


The set Ax contains the redexes that may occur in any context (opera- 
tions/steps of artifact instances, or run-time activities of agent instances), 
the set V4 contain the redexes that may occur only in (operations/steps of) 
artifact instances, and the set VY contains the redexes that may occur only 
in (activities of) agent instances. 

The following proposition states that evaluation contexts and redexes 
decompose expressions in a unique way (the proof is straightforward by 
structural induction on expressions). This proposition assumes that our set 
of definitions is well typed, which is the assumption we made at the end of 
the previous section. 


Proposition 1 (Unique decomposition of expressions) Given an ez- 
pression e, either e is a value or there is a unique evaluation context E such 
that e = E€[rdx] for some rdx. 


Evaluation contexts for (expressions in) activities are defined as follows 


Roux a(w)[ ]{E} | a(w)[Sr R Sr|{e} 
| a(w)[Sr P Srj{e} 
P w= a(v)(E,e) | alv)(tr,é) | alvEe)(e,e') 


If an activity does not have sub-activities that have to be evaluated, then 
the context selects the subexpression of its body that needs to be evaluated, 
otherwise it (non-deterministically) selects one of its sub-activities with 
the context P. The sub-activity may be a running activity (in which case 
one of its subexpressions is evaluated), or one which specifies that the 
evaluation of its parameters or persistence predicate or precondition is not 
yet completed. In this case: first the parameters are evaluated left to right, 
then the persistence predicate, and finally the precondition. 
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For activities we also define a context S that (non-deterministically) 
selects a sub-activity. 


Sus () | al)Sr SSz]{c} 


This context is needed when we want to identify a whole sub-activity, such 
as when we have to schedule execution of sub-activities, whereas the context 
R selects an expression within an activity. 


Operation evaluation contexts are defined as follows 


O x= (o,o(w)[St](E){e}) | (7, 0(¥)[St](tr){E}) 
| (a, 0lo(v)(f1s) o'(v)(€) St) 


where with o(v)(fls) we denote a sequence of steps all with guard equals to 
fls. For an operation we first evaluate the guard expression, and in case 
this is tr we also evaluate its body. Guards of steps are evaluated left to 
right while the guard evaluates to false. 


Finally, to account for the redexes that may occur in activities and operation 
bodies (spawn G(v), make A(v), and v;e) we define agent/artifact instance 
evaluation contexts, by 


se Hevea RY: || wait v p= 1770-0)" 
Note that, for artifact instances, the context selects the last operation of the 
sequence of running operations, which is the running one. 


3.3.4 Initial Configurations and Reduction Relation 


Evaluation of an executable program starts from its initial configuration 
defined as follows. 


Definition 2 (Initial configuration) A program (GT, AT) is executable if 
the agent table GT contains an entry for an agent with distinguished name 
Main of the shape 


agent Main { activity main() :agenda() {e;} } 
The initial configuration associated to the executable program (GT, AT) is 
7 = (0,0,main()[]{e})"* 


for some reference 7+. 
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M=M Mo —M 
g ? [EMPTYCONT] 
M> MM 
M=M|M M M 
[Bip = Mee [CONT] 
MSM | My 


Figure 7: Reduction rules: configuration congruence 


For example, for our system of Figure 1, the initial configuration is: 
yu = (0,0,main( )[ {spawn Init(make Counter(0)); })"*"" 
Note that, we can write the initial configuration as: 
K|make Counter (0) ] (1) 


where K is 
yu = (0,0,main( )[ ]{spawn Init([ ])})""" 


In the following, to shorten configurations, we will use for names of agents 
and artifacts just the first letter of their name. 

The reduction relation has the form M => M’ meaning that the config- 
uration M reduces to configuration M’ in one step, where configurations are 
defined as follows: 

M s:= I | (M|M) 

Ls] So} || eS (ha pH we. 0) | Pe 
and the configuration congruence relation, =, formalizes the fact that config- 
urations represents non-empty sets of instances, that is: 


(M| M’) = (m’ | M) ((M|M’) | m") = Ot | (wt | M”)) 


We use the congruence relation between configurations in the definition 
of the relation =, see rules [EMPTYCONT] and [CONT] of Figure 7. 
Such rules rearrange agents/artifacts/sensors instances in order to apply 
the reduction —> for minimal configurations. Minimal configurations are 
configurations containing exactly the agent /artifact /sensor instances involved 
in the reduction. We write =* for the reflexive and transitive closure of >. 

The rules in Figure 8 generate agents and artifacts. Creation may occur 
in any context. Creation of an agent, rule [AGN], in addition to creating a 
binding between a fresh identifier ~y and an instance of an agent, creates m 
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instances of sensors corresponding to the sensor identifiers declared in the 
agent. The main activity is also started, setting up its sub-activities. Since 
sub-activities have to be evaluated at least once, the persistence predicate 
is set to tr. Parameters, persistence predicate and preconditions of sub- 
activities may contain the formal parameters of the activity, therefore they 
are substituted with the actual parameters of spawn G. For an artifact, rule 
[ART], we create a binding between a fresh artifact identifier and an artifact 
instance. Moreover, the fields and properties of the artifact are initialized to 
the actual parameters of make A. 

Take our initial configuration (1). The first (and only) reduction possible 
is using rule [ART], that is 


(1) > K]Jac] | ac = (0, count = 0,0, 0)° 


and 
K[ac] = K'[spawn I(ac)] where K’ is 74 = (0,0,main( )[]{[]})" 
applying rule [AGN] to K'[spawn I(ac)] we get 
ya = (0,0,main()[]{vz})" | a = 0,0, main(ac)[]{e1; e2; e3})* (2) 


where (i) e; is spawn O0(ac), (ii) eg is spawn U(ac), and (iii) e3 is spawn U(ac). 
Most of the time configurations have more than one instance of agent, 
artifact, or sensor in parallel. So to reduce configurations we apply [CONT] 
(or [EMPTYCONT] if we just need to rearrange the term) with the chosen 
rule applied to the minimal configuration on its premises. In the following we 
will just show examples of application of the rule to minimal configurations. 
The means by which => is obtained should be obvious. Applying [AGN] 
to yr we generate a new agent instance of type Observer, and since there 
is a sensor declared in its definition, we also generate a sensor instance. 
The main activity of the agent Observer has two sub-activities: prepare 
and monitoring whose persistence predicate is initialized to tr and the 
precondition to the one specified in the definition of the sub-activity. 


K" [spawn O(ac¢)]] — (3) 
K" [yo] | Yo = (0, ¢,main(ac)[S1 $2] {})° | o = (0)"* 


where kK” is 


yo = (0,0,main( )[ ]{[]; spawn U(ac); spawn U(ac)})" 
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y fresh activity main (TX) sagenda(SubAct +++ SubActn){e;} €G 
(for allt € 1.) SubAct; = a;(@’) bus e, :pre e, 
Sr; = a:(8'[w/z)) (tr, ef fv /z)) 
Sns S1,...,8m €G SO ae (for all 7 € 1..m)  o; fresh [AGN] 
K|spawn G(v)] —> 
KEI [7 = 0,3 main(9) [Se --- Sen]{e[e/z]})° 
Jor = (DY |---| om = (8) 
a fresh UEVpE 
Kmake A@=)] —> KloJla = @=¥,p=0 0,0" Bae] 
Klv;e] — Ke] [SEQ] 


Figure 8: Reduction rules: agent and artifact instances creation, sequential 
composition 


and 
e Si = prepare(ac)(tr, tr), and 
e S2 = monitoring(ac)(tr, completed(prepare)). 


Note that the persistence predicate of the sub-activity prepare is initialized 
to tr (even though it was declared to be fls) so that the sub-activity is 
scheduled a first time. As we will see later, when at the end of its execution 
it is rescheduled again, then its persistence predicate will be initialized to 
its definition. This causes exactly one execution of the sub-activity prepare. 
Let us now assume that we apply [SEQ] that removes the value in the hole 
of the agent yo. At this point the evolution of the system can go on either 
spawning a User agent or starting the evaluation or scheduling the execution 
of the sub-activity prepare, see rule [SCH] of Figure 10. Let us assume that 
we spawn the two User agents and produce the following configuration: 


ym = (0,0,main( )[]{ })"| a = (0,0, main(ac)[ }{ })* | 
ac = (0, count = 0,0, 0)° | (4) 
Yo = (O, ¢,main(ac)[S1 S2]{})° | yi = (0, 01, main(ac)[SAvi]{})” | 


SAva]{})" | o = (O)* | o1 = (O)* | a2 = (0) 


Yu: = (0,2, main(a c) 


where SAy; and SAyo denote usingCount(ac) (tr, tr). 
In Figure 9 we present the evaluation rules for expressions that may 
occur only inside activities (and therefore agents). The first three rules deal 
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with agent memos. Rule [MMmatch] is for reading, removing and querying 
memos in the agent memo-space when the memo is present. When the 
specified memo is not present in the agent memo-space, rule [MMmismatch] 
generates a failure in case we try to read or remove, and returns fls if we 
queried for presence of the memo via the predicate memo(1). Rule [MMins| 
inserts the memo in the memo-space. 

Rule [SNS] returns a reference to the instance of the sensor corresponding 
to the identifier s (see rule [AGN] for the initialization of the sensors). If 
an agent is well-typed there is always a sensor instance corresponding to 
s. Rule [PER] extracts the first value associated with a specific label from 
a sensor, in case no association for 1 is found the rule is not applicable, 
therefore the activity is blocked. In this case, the presence of the label is a 
run-time condition that may be used for synchronizing agent activities. 

Rule [GETA] reads property p; of agent a. Rule [FOC], and [UNFOC}] 
start/stop focussing on the events of an artifact by inserting/removing the 
sensor in the list of sensors of the artifacts. 

Rule [USE] starts the operation o on the artifact a with parameters V 
defining o as the operation sensor. The operation is enqueued in the queue 
of operations for the artifact a. Therefore, as we will see from the rules of 
Figure 12, it will be the last one to be scheduled for execution. 

Rule [FAIL] propagates a failure in an activity by replacing the activity 
with a failed activity—this is a very primitive way of dealing with failure, 
simplifying the actual sIMPA management of failures which is based on 
standard try/catch constructs. 

The last three rules check the state of the execution of sibling sub- 
activities. The predicate completed(a), rule [COMPL], checks the presence 
of the sub-activity a in the list of sub-activities. (When an activity is started 
the evaluation of the sub-activities in its agenda is started by putting them 
in the list of sub-activities, and when the evaluation of a sub-activity is 
completed, the sub-activity is removed, so the list contains the sub-activities 
not yet completed.) The auxiliary function actNames() is defined as follows 


actNames(Sr) = {a | ale elie ESE 
or failed*® € Sr 
oral eter se sr} 


Rule [STARTED] checks whether a is in the list of sub-activities and it is a 
running activity. The auxiliary function actStarted() is defined as follows 


actStarted(Sr) = {a | a(---)[---]{---} © Sr} 
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Finally, rule [FAILED] checks whether or not the sub-activity failed. 

In Figure 10 we present the rules for scheduling the execution of sub- 
activities. When an activity starts its execution, the sub-activities in its todo 
list are put in the pool of sub-activities that needs to be evaluated with tr 
as persistence predicate. Therefore, the evaluation of their precondition can 
start. If the evaluation of the precondition produces tr, rule [SCH] starts 
the evaluation of a sub-activity, named a, whose persistence predicate and 
precondition are true. As already mentioned, since the sub-activities of a 
have to be evaluated at least once, the persistence predicate is set to tr. 

Preconditions may evaluate to fls, in this case, rule [PREC] restarts 
the evaluation of the precondition. The body of the precondition is found in 
the agenda of the activity a. Since this precondition may contain the formal 
parameters of the activity a of which a; is a sub-activity, in the expression 
the formal parameters of a must be substituted with the actual parameters 
at the time he activity was started. 

Rule [DISP] removes a sub-activity whose persistence predicate is false. 
Note that, from rule [SCH], the persistence predicate may be fls only after 
the first evaluation of the sub-activity. Indeed sub-activities that have to be 
executed only once have persistence predicate fls. 

Rule [END-SA] restart the evaluation of the parameters, persistence 
predicate and precondition of a completed sub-activity, a’. The value v 
resulting from the evaluation of the sub-activity is inessential. Note that in 
this case, since the sub-activity a’ has already been evaluated at least once, 
the persistence predicate to be evaluated is the one specified in the agenda 
(with the substitution of parameters). 

Going back to our configuration (4) we can schedule, applying [SCH], 
either the sub-activity prepare of the agent yo, or one of the sub-activities 
usingCount, of the agents yy, or yu2 because all these sub-activities have 
both predicates equal to tr. Assume we schedule prepare of the agent yo. 
In the configuration of (4) the only think that changes is that sub-activity 
S1 (prepare) from a sub-activity that was evaluating its predicates becomes 
a sub-activity that is executing its body 


yo = (0,0, S(main(ac)[S1 S2]{ }))° — yo = (0,0, S(main(ac)[S1’ S2]{ }))° (5) 


where the evaluation context S is (}), and $1’ is 


prepare(ac)| |{focus(ac,s); } 
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Figure 9: Reduction rules: agent instance basic instructions 
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so that the body of prepare could be executed. To the configuration on the 
right-side of the arrow of (5) we can apply rule [SNS] that is 


Yo = (0,0,R[-s])° Tt YOR (0,0, R[ac])° (6) 


where 
1. R is main(ac)[Ri S2]{ }, and 
2. Ri is prepare(ac)| |{focus(ac, | ]); }. 


Since in the configuration (4) we have the artifact a¢ we can apply rule 
[FOC], that is: 


ac = (0, count = 0,0, 0)° | 
gyc 


ac = (0, count = 0,0,0)° | 


where FR is as 1. above, and FR, is [ ]. The effect of [FOC] has been to add 
the sensor o private to the agent yo in the list of sensors of the artifact ac. 
To yo we can apply [END-SA], ie., 


Yo = (b,c, R[focus(ac, a])° — 
Yo 


= (0,0,RIo])° (7) 


Yo = (0,0,S5(main(ac) [prepare(ac)| ]{o} S2]{ }))° — (8) 
Yo = (0,0,S(main(ac)| prepare(ac)(fls,tr) S2 ]{ }))° 


As mentioned before, when a sub-activity is completed the rule [END-SA] 
substitute the sub-activity with a pre-activity, that is the evaluation of the 
persistence and precondition predicates of the activity. The persistence 
predicate we use is the one of the declaration of the the sub-activity in the 
code of the agent, that in this case is f1s. We can now show an example of 
the application of rule [DISP] that removes a sub-activity having persistence 
predicate f1s from the list of sub-activities (remember that the body of an 
activity is evaluated only when the list of its sub-activities is empty. This is 
realized by the first clause of the definition of R). So applying rule [DISP] 
we have 


Yo = (0,0,S(main(ac)| prepare(ac)(fls,tr) $2 ]{ }}))° — (9) 
Yo = (0, 0,5 ((main(ac)| $2 ]{ }))° 


Considering the application of the rule [COMPL] to the predicate 
completed(prepare) of S2 for the configuration on the left side of the 
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reduction arrow of (9) produces f1s, whereas for the one on the right side 
of the arrow produces tr. 

Assume that we apply rule [SCH] to the agent yz; of the configuration (4), 
since both persistence and precondition predicates are tr 


qi = (0,01, 5 (main(a¢)[SAyi]{ }]))” — (10) 
qui = (0,01, S(main(ac)[usingCount(ac)| |{use c.inc() : sns s; }]{ }]))° 
where the evaluation context S is ({ ]). Now another application of rule [SNS] 
similar to (6) produces 


yu1 = (0,01, S(main(ac)[usingCount(ac)[ |{use c.inc() : sns 01; }]{ }))” 


Since in the current configuration we have the artifact ag we can apply rule 
[USE], that is: 


ac = (9, count = 0,0,0)° | yu1 = (0,01, RJuse c.inc() : sns o,])° — 
Ac = (0, count = 0,0, (01, inc( )[ ](tr){.count = .count + 1}))° | (11) 
Yu1 = (0,0, R[oi])” 


Note that now the artifact ac contains references to two sensors. One, 01, 
is local to the running operation inc and it is used for explicit signal 
expressions that could be evaluated in the body of the operation. The other, 
a, is global to the artifact and is used to signal more general events such as 
updating of properties or end of operations. 

In Figure 11 we present the evaluation rules for expressions that may 
occur only inside operations (and therefore artifacts). Rules [GET] and 
[SET] return/modify the value of a field. Rule [GETPR] return the value of 
a property whereas rule [SETPR] sets the value of a property, and moreover, 
sends the event of updated property to all the agent focusing on the artifact, 
by inserting in the sensors focusing on the artifact the label prop_updated(p;) 
associated with the value to which the property was set to. 

Rule [GEN] signals the event 1 with value v by adding the association 
between 1 and v to the sensor associated to the operation, and also to all 
the sensors of all the agents focusing on the artifact. 

Rule [NEXT] generates a new step, adding it to the sequence of steps 
of the operation. Note that the last two expressions, as well as field and 
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activity a’ (TX) :agenda(SubAct;---SubAct,) {e;} €G 
SubAct; = aj(@)’ :perse, :pree’ (1<i<n) 
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7 = (S(a(w)[Sr_a’(w)[]{v} Sr']{e"”}))° — 
7 = (~~S(a(w)[Sr_a’(e[w/x])(e' [w/z], e” [W/x]) Sx"]{e"”}))° 


Figure 10: Reduction rules: agent instance scheduling of sub-activities 


property update may only occur in the evaluation of the body of an operation 
(and not in the evaluation of its guard that is side effect free). 

Assume that we schedule the execution of the operation inc of ac. 
First, as the evaluation context for expressions require, we have to evaluate 
the right-hand-side of the assignment to the property count. Even though, 
we do not have arithmetical operations in our definition of expressions, we 
can assume that they are evaluated by first evaluating their arguments and 
them returning the result of the arithmetical operation. So 


ac = (0, count = 0,0, (01, ine( )[ ](tr){.count = .count + 1}))° 


can be written as 


ag = (0, count = 0,0, O[.count])° 
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where QO is (oi, inc( )| ](tr){.count = [| ]+1}). We can apply rule [GETPR] 
that. is: 


ac = (9, count = 0,0, O[.count])° — ac = (0, count = 0,0, O[0])° (12) 


Assume that the evaluation of the expression 0 + 1 produces 1, the artifact 
can be written as 


ac = (0, count = 0,0, (01, inc( )[ ](tr){E[.count = 1]}))° 


where € is [ ]. The application of rule [SETPR] is as follows: 


Ac = (0, count = 0,0, (01, inc( )[ ](tr){E].count = 1]}))° | o = ()5"5 —> 
ac = (0, count = 1,0, (01, ine( )[ ](tr){1}))° | o = (1 1)85 - 


where 1 is prop_updated(count). So now if the Observer agent that focused 
on the artifact is sensing the change of property count, it would get as result 
the new value of the property. 

In Figure 12 we present the state change rules for artifacts. Note that, 
given the definition of K, and the rules in Figure 11 the operation that is 
evaluated is always the last of the sequence (first of the queue). When the 
guard of an operation is tr and the body is fully evaluated, there are two 
cases: either some step was generated (during the evaluation of the body), 
in which case rule [SELG] removes the current operation from the queue 
and enqueues the step evaluation expression of the sequence of steps; or no 
step was generated, that is, the operation is completed and can be dequeued, 
rule [END]. In addition, rule [END] signals to all the agents focusing on the 
artifact the completion of the operation. Since there is no value associated 
with this event we use the value unit. 

When the guard of an operation evaluates to f1s, with rule [FLS], the 
operation with its guard is dequeued and again enqueued in the queue of 
operations (so, when its turn comes, it will be reevaluated) Note that, no 
step could be generated during its evaluation since the guard is side effect 
free. 

The last two rules are applied when the operation in execution is the 
evaluation of the guards of operation steps. If a guard of a step evaluates 
to tr, then the evaluation continues with the body of the step, rule [SGO], 
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Figure 11: Reduction rules: artifact instance basic instructions 


and everything else is disregarded. If instead all the guards of the steps 
evaluated to f1s, with rule [SKIP] their evaluation is rescheduled and put 
at the beginning of the sequence. 


An application of rule [END] is as follows: 


(0, count = 1,0, (1, ine( )[](tx){1}))° | # = (11)8* 
(0, count = 1, 0, oye | c= (1 unit 1 1\ee5 


“a (14) 


Qc 
(67%) 


where 1’ is op_exec_completed(inc). This event could be sensed by the 
Observer agent that focused on the artifact. 
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Figure 12: Reduction rules: artifact instance state change 


4 FAAL Type Soundness 


This section shows that FAAL enjoys the standard type soundness property 
of statically typed languages. Namely, the execution of a well-typed program 
does not get stuck: that is, if a running agent has some ongoing activity 
or an artifact has some operation to perform, then there is some rule 
that can be applied. To state the type soundness result for FAAL we 
introduce a suitable notion of typing for configurations, show that the initial 
configuration of a well-typed program is well-typed, and that reducing a well- 
typed configuration produces a well typed configuration (subject reduction). 
Moreover, we show that if an agent it is not sensing an event or it does not 
have failed sub-activities, then some rule is applicable (progress). In this 
section we only state the main results, whose (technical) proof is given in 
the Appendix. 


4.1 Well-Typed Configurations 


In order to give types to run-time expressions we have to modify the 
type system by replacing the type environment TI (mapping variables to 
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activity a(Tx) ---€G 


“lke: Bool ING activity a(Tx) ---€G 

Uk e’ : Bool ING (for alli € 1..n) “lk Sr; OK ING 
Ulke: TING Ulke:--- ING Uikv: TING 
UlF a(e)(e,e’) OK ING “ilk a(v)[Sri---Sr,]J{e} OK ING 


“IF ROK ING agent G { Sns s1---Sn; ---} 
activity a---€G (for allo €o1-+-on) U(o) = Sns 
IF failed* OK ING Slik y= (19,c,R)° ok 


Figure 13: Well typed run-time sub-activities/activities and agent instances 


types) with the run-time type environment ©, denoted by [7 : T], mapping 
agents/artifacts/sensors references to types. The new typing judgement 


“lk e:TINX 


means that, under the assumptions in ©» for references, the expression e has 
type T in the context of an instance of the artifact or agent X. The rules of 
the system are obtained from the rules of Figure 4 by replacing [ with &, 
and replacing rule [Tvar], with 


“lke: Ue) INX_ [Tid] 


The typing of run-time expressions is used to define well typed configu- 
rations. In particular the judgments for: 


e run-time sub-activities/activities and agent instances are given in 
Figure 13; 


e run-time steps/operations and artifact instances are given in Figure 14; 
e run-time sensor instances are given in Figure 15; 


e configurations are given in Figure 16, where the auxiliary function 
typeEnv is defined by: 


typeEny (iy aiorey" [see ieea dee) = lest Tissot? Ta 


Note that if M ok, andM=M’, then + M’ OK. 
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“lke: Bool INA _ e side effect free 


“lke:Bool INA Vike’ :--- INA 

e side effect free operationo ---€A or stepo::-EA 
step o(Ux) ---EA (a) = Sns 

SIF V:UINA (for alli €1..n) “lk St; OK INA 

“lk o(v)(e) OK IN A VIF (o, o(¥)[Sti---Stn](e){e’}) OK INA 


“ilk (o,0[Sti---St,]) OK INA 


artifact A{Tf;T p; ---} 
Sikv:TINA Cikw:T INA 
(for allo €o) (oc) =Sns 

(for alli€1.n) “lk 0; OKINA 
SIF a= (v¥,pw,o,01---0,)* oK 


Figure 14: Well typed run-time steps/operations and artifact instances 


typeOfLab(1) = typeOf(v) 
DIF o = Aw™ oK 


Figure 15: Well typed run-time sensor instances 


typeEnv(Ii |---| In) = (for allt €l1.n) Ulk I; OK 
FI,|---|In OK 


Figure 16: Well typed configurations 
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4.2 Type Soundness 


In this section we state Subject Reduction and Progress for well-typed 
configurations, and Type Soundness of well-typed programs. In the following 
we assume that the program containing the definition of the agents and 
artifacts is well-typed, i.e., F (GT, AT) OK. 

The subject reduction theorem says that by reducing a well typed 
configuration we obtain a well typed configuration. 


Theorem 1 (Subject Reduction) [f+ M oK andM=>M™, then M’ oK. 


Proof: The proof is given in Appendix A.1. 

In order to state the progress result we define when an agent has 
completed its task, successfully or with failure, and when an agent is blocked 
in a configuration, that is the agent cannot reduce. This is if all its activities 
are doing a sense on sensors not containing the specified label (so to proceed 
in the evaluation of the activity the agent has to wait for some artifact to 
signal on those sensors). 


Definition 3 (Completed agent) The agent instance y = (1¥,¢,R)° is 
completed if R = failed™", or R = main(v)| |{v}. 


Definition 4 (Blocked agent in a configuration) Let M=1, |---| In 
be a configuration. 


e The expression e is blocked in M if e = E|sense o :filter 1], and 
there exist j € 1..n such that 1; is o = (1 v’)®"5 andl ¢T’. 


e The activity a(v)[ Sri---Srm |{e} is blocked in M if 


1. either m = 0, and e is blocked in M, or 


2. m> 0, and for alli, 1<1<™m, either Sr; is is blocked in M, or 
Sr; = failed? for some a’. 


e The agent y = (1v,7,R)° is blocked in M if R is blocked in M. 


Note that in the definition of blocked activity we require that the sensor 
on which the activity is doing the sense be defined. The type system will 
ensure that the required sensor is present. Obviously, absence or presence of 
the label is used to coordinate agents and artifacts. 

An artifact is idle if it does not have any pending operation. 
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Definition 5 (Idle artifact instance) An artifact instance a = (f = 
v,p =w,a,0)4 is idle if0=9. 


Theorem 2 (Progress) Jf MOK, M= I, |---| In and (for some i € 
l..n) I; is an agent non-completed and non-blocked in M, or a non-idle 
artifact, then M =’ for some WM’. 


Proof: The proof is given in Appendix A.2. 


Theorem 3 (Type Soundness) /fI is the initial configuration of (GT, AT) 
and I >* M withM=TI, |---| I, not reducible, then + M OK and (for all 
i€ 1..n) I; is either a sensor or an idle artifact or a completed or blocked 
agent. 


Proof: First observe that, if I is the initial configuration of (GT, AT), then 
+ I OK (the proof is straightforward by induction on expressions). Then, 
the result follows immediately from Theorems 1 and 2. 


5 Related Work 


The literature related to the present paper has been partially quoted in the 
introduction. We add here comparisons and remarks concerning core calculi 
for agents, actors and concurrent objects. 

In the Agent-Oriented Programming literature, many contributions 
introduced a formal semantics for abstract or concrete agent programming 
languages, with the purpose of providing a rigorous and formal account 
for the design, specification and verification of agent programs. One of 
the first examples is [29], which describes the operational semantics of an 
abstract BDI-based agent programming language, combining features of 
logic programming and imperative programming. Actually, operational 
semantics has been widely adopted to formally describe the behaviour of 
agent programming languages and frameworks (e.g., [50, 57]|), as well as of 
specific aspects of multi-agent systems, such as agent communication (e.g., 
[46, 22]), agent organisations (e.g., [23]), etc. Examples of concrete agent 
programming languages which enjoy a formal operational semantics are 
Jason [9], 2APL [19] and GOAL [30]. 

In all these works, the operational semantics is used essentially to 
specify formally the behaviour of the agent (abstract) machines executing 
agent programs. To the authors’ knowledge, no investigations about a type 


306 F. Damiani, P. Giannini, A. Ricci, M. Viroli 


system supporting standard type soundness for an agent-based programming 
framework have been developed so far. The most direct attempt that has 
been done so far applying formal modelling techniques like core calculi to 
study properties of agent-oriented programs and of agent-oriented extensions 
of object-oriented systems is [52], to which the present work is mainly an 
extension. Such a formalisation, however, lacks a type system that is able 
to guarantee well-formedness properties of programs. Building on top of 
[52], this paper formalised a larger set of features (including agent agenda 
and artifact properties) and provided a type soundness result. In [17, 18] 
we introduced a core calculus for agents and artifacts (of which the current 
calculus is an extension), outlined its operational semantics, and discussed 
its main properties. 


Core calculi and type systems are applied to programming frameworks 
which, although not strictly agent-based, have many similarities that are 
worth mentioning. In [{11, 44] a calculus is introduced on a very weak notion of 
agent, namely, an active entity (like an actor or process) exchanging messages 
asynchronously. Accordingly, such a formalisation does not consider the 
environment and related concepts, concerning percepts and actions, which 
are instead a core part of FAAL. These aspects are considered instead in 
the layered agent calculus [38], which is not introduced — however — for 
formalising the features of an agent programming language. 


In their seminal book [1], Abadi and Cardelli develop a theory of 
objects as a foundation for object-oriented languages and programming, 
and introduce some object calculi, which are formalisms at the same level 
of abstraction as function calculi, but based exclusively on objects rather 
than functions. They study both functional/imperative and untyped/typed 
systems. Our modelling of artifacts, which can be seen as asyncronous 
objects, is inspired to their imperative calculi. However, concurrency, situat- 
edness and autonomy, are not considered, and therefore agents, cannot be 
straightforwardly modelled with such calculi. 


A number of core languages have been proposed for actors and object- 
oriented concurrent programming, almost all of which are based on some 
kind of process calculi. Examples are: CAP [12], a process calculus based 
on the actor model; Honda and Tokoro’s object calculus with asynchronous 
communication [31]; the Join calculus [24], which has been used in the 
formalisation of features of various concurrent programming languages (such 
as Polyphonic C# [6] and JOIN JAVA [36]); and STATEJ [16, 15] (see also [14, 
13]), that proposes state classes, a construct for making the state of a 
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concurrent object explicit. 

Type systems have been widely used for analysing the behavior of 
concurrent programs and systems of concurrent processes, to reason about 
deadlock-freedom, safe usage of locks, etc. [64, 41]. Typically, variants of 
the z-calculus [45] are used as target language. Some process calculi ex- 
tending the z-calculus have been introduced to model specifically mobile 
agents [25, 48, 20]. Nomadic Pict, see [55], emphasizes location depen- 
dence/independence, and provides a distributed infrastructure, see [56], for 
the migration of mobile agents. The Distributed-7 calculus [28, 27] is a 
typed language for mobile agents extending the z-calculus with an explicit 
notion of location that represent the environment where such agents are 
currently located. The type system is based on the notion of location types, 
which describe the set of resources (i.e., typed channels to communicate 
with other agents) available to an agent at a location. The notion of type in 
this case is introduced for controlling the use of resources in a distributed 
system. 

Finally, the notion of session type has been introduced to specify complex 
interaction protocols, verified by static typechecking [32]. In the core calculus 
presented the interaction between agents and artifacts, and the dependency 
between actions and sub-actions is programmed via predicates: preconditions 
for activities and guards for artifacts. Session types, and in particular 
multiparty session types (see [33]), could be used to impose (and verify 
statically) restrictions on the pattern of interaction, as hinted in the following 
section. 


6 Conclusion and Further Work 


The FAAL calculus provides a first step towards a rigorous formal framework 
for designing agent-oriented languages and studying properties of agent- 
oriented programs. It enjoys the standard type soundness property of 
statically typed languages. Namely, the execution of a well-typed program 
does not get stuck: that is, if a running agent has some ongoing activity or an 
artifact has some operation to perform, then there is some rule that can be 
applied. In particular, the type system has been designed to guarantee that 
a number of properties are satisfied, including the following: (i) agents may 
execute (and query) activities and access sensors only if these are defined for 
them; (ii) agents may invoke operations and observe properties only if these 
are defined for the target artifact; (iii) artifacts may only access/modify 
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fields and properties defined for them; and finally, (iv) channels (sensors) 
supporting the communication between agents and artifacts are typed so 
that they signal values of known types. 

Future work will be focussed on two main directions. The first direction 
concerns enriching the current language and its formal model. In particular, 
we are investigating the suitable definition of pre/post/invariant conditions 
in terms of sets of memos that must be present or absent in the memo space, 
so that it would be possible to represent high-level properties related to 
the set of activities, such as the fact that an activity A would be executed 
always after an activity A’ or that activities A and A’ cannot be executed 
together. The second direction is about studying and defining agent calculi 
and type systems for agent oriented programming languages based on high- 
level models/architectures, such as BDI (Belief Desire Intention) [49], which 
is one of the main references in programming rational/intelligent agents. 
Differently from sIMPA, such languages adopt high-level cognitive concepts — 
such as tasks, goals, plans, beliefs — to define agent structure and behaviour. 
A medium-term goal we believe can be reached is to substantially fill the 
gap between object- and agent-orientation, fostering the adoption of new 
metaphors, abstractions and patterns for tackling the concurrency issue. 
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APPENDIX 
A Proofs 


A.1 Proof of Theorem 1 (Subject Reduction) 


Both the type system for programs (system +, presented in Section 3.2) and 
the type system for configurations (system IF, presented in Section 4.1) are 
syntax directed and enjoy the inversion property. The inversion property 
for the typing rule for configurations (in Figure 16) is given by Lemma 1.1 
below. We do not give the inversion lemmas for the other rules of systems F 
and IF since they are trivial. Let X range over agent /artifact types and let 
Y range over agent/artifact types and C. 
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Lemmal 1. /f+ I; |---| In OK and typeEnv(I; |---| In) = %, then 
“lk I; oK (for alli € 1..n). 


2. Let Ulk I OK, then there exists a type T such that 


Proof: 
1. By definition of well typed configurations, see Figure 16 


2. By structural induction on the contexts R and O (see Section 3.3.3) 
using the typing rules in Figures 4, 5 and 6. 


Lemma 2 (Weakening) /f/F I ok and’! 5%, then’ |r I ox. 


Proof: Straightforward, by induction on derivations. 

To simplify the presentation, we define a context G that (non determin- 
istically) selects a sub-activity in an agent instance (the context S has been 
defined in Section 3.3). 


G s= y=(1v,0,S)% 


Lemma 3 (Replacement) 1. Let % lk Kle] OK and» lk e: TIN X, 
then Slt e’ : TIN X implies S| K[e’] oK. 


2. Let S|k G[Sr] OK and Slt Sr OK ING, then X IF Sr’ OK IN G implies 
SIF G[sr’] ox. 


Proof: Straightforward, by induction on derivations. 


Lemma 4 (Substitution) 1. [f[k x’: XC] e:TING, andtype0f(v) = 
C, then [7 : X] Ik eft v/x X’]: TING. 


2. If|xx’: YC] e: TINA, and typeOf(v) =C, then [c: Y] lt eft v/x x’ : 
TIN A. 


Proof: Straightforward, by induction on expressions. 


Lemma 5 (Subject Congruence) Jf MOK andM=M’, then} M’ oK. 
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Proof: Straightforward, by using Lemma 1.1. 


Lemma 6 (Subject Reduction) 1. Jf Mj OK and Mo —> M, then 
E M, OK. 


2. If M | Mo OK and Mp —> Mj), then M | My OK. 


Proof: We consider the proof of 1. (the proof of 2. is similar). The proof 
is by case analysis on the operational semantics rule (in Figures 8, 9, 10, 11 
or 12) used. Cases [SEQ], [MMmatch] (only first conclusion), [MMmismatch], 
[SNS], [GETA], [COMPL], [STARTED], [FAILED], [GET] and [GETPR] 
are immediate by Lemma 3.1. Cases [FAIL] and [DISP] are immediate by 
Lemma 3.2. 

Case [AGN]. We have © Ik K[spawn G(v)] ok. Let ©’ = YU [y = 
G,o, : Sns,...,0m : Sns]. By Lemmas 2 and 3.1 we have »’ Ik Ky] ox. 
From | agent G {---} Ok, by inversion for +, Lemma 4.1 and the typing 
rules in Figure 13 we get D/ lk y = (0,0,main(v¥)[Sr1 ---Sr,]{e[v/x]})° oK. 
By the typing rule in Figure 15 we get ©! Ik oj; = (0)8"5 ok (1 >i 
m). Then, by the tying rule in Figure 16 we get ©’ Ik Ky] | 7 
(0, F, main(v)[Sr1 ---Sr,]{e[v/x]})° | o, = (0)S"8 |---| om = (0)82 OK. 

Case [ART]. Similar to the previous case. 

Cases [MMmatch] (second and third conclusion), [MMins], [PER], [FOC] 
and [UNFOC]. Straightforward by using Lemmas 1 and 3.1. 

Case [USE]. Straightforward by using Lemmas 1, 3.1 and 4.2. 

Cases [SCH], [PREC] and [END-SA]. Straightforward by using Lemma 3.2 
and 4.1. 

Cases [SET], [SETPR], [GEN], [SELG] and [END]. Straightforward by 
using inversion. 

Cases [NEXT], [FLS], [SGO] and [SKIP]. Straightforward by using 


inversion and Lemma 4.2. 


Il IV 


Proof of Theorem 1 (Subject Reduction): 


By case analysis on the operational semantics rule (in Figure 7) used. Case 
[EMPTYCONT] follows by Lemmas 5 and 6.1. Case [CONT] follows by 
Lemmas 5 and 6.2. 
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A.2 Proof of Theorem 2 (Progress) 


Let the set of expressions be partitioned in the following sets: 


Ex = {spawn G(é),make A(@),e1;e2,v} 
&, = {.f,.f =e,.p,.p=e,next 0(€),signal(1(e))} 
€; = {.s,use e2.0(@) :sns e,,sense e :filter 1, 


?memo(1), -memo(1), +memo(1(e)),memo(1), 
focus(e,, e2), unfocus(e, e2), observe e.p, 
completed(a), failed(a), fail} 


Lemma 7 Let y = (1¥,0,R)° be an agent instance, and let © Ik y = 
(Iv,o,R)° oK for some X, and+ agent G { Sns 8; Act} OK. Then R 
contains only (sub)expressions in Eg U Ex, or identifiers in 8, t.e., R does not 
contain variables, or identifiers not in 8, or expressions in Ey. 


Proof: Observe that the typing rules of Figure 4 and 5 are such that only 
expressions in & U €x are allowed in activities, and only sensor identifiers in 
8. The rule for agent creation, [AGN] of Figure 8, replaces all the variables 
in the body of the main activity of the agent with values, and the reduction 
rules of Figure 9 replace expressions in €& U €x with either values or the 
expression fail € €. Finally the rules for scheduling of agents of Figure 10 
are such that only expressions in €g U €x and not containing variables are 
inserted in the running activities. 


Lemma 8 Let y = (1¥, 
stance, let S lk y = (1¥, 
Then 


a,R)*° be a non-completed and non-blocked agent in- 
a,R)° ok for some d, and agent G { Sns 8; Act} OK. 


1. there is R, and rdx such that R = R[rdx], rdx € XU Ax. Moreover, 
(a) if rdx is started(a), or failed(a), or completed(a), then R = 
S(a/(v)[Sr P[rdx] Sr’|{e})), for some S, P, a’, v, Sr, Sr, ande; 

(b) if rdx = fail then R = S(a’(v)[ |{E[rdx]})), for some S,€,a’, v; 


or 


2. R=S(a(w)[Sr a’(v)(v,e) Sr’]{e’}] for some for some S, a, a’, W, T, 
Sr, Sr, v, e, ande’ such that: v= tr implies e =v’ for some v’ 
or 

3. R= S(a(w)[Sr a’/(v)[]{v} Sr’]{e}) for some S, a, a’, W, ¥, Sr, Sr’, 
v, ande. 
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Proof: Since the agent is non-completed R is main(v)[Sri---Srp|{e}, and 
n = 0 implies that e is not a value. 

If n = 0, from Lemma 1 there is a unique evaluation context € and redex rdx 
such that such that e = €|rdx]. From Lemma 7 rdx € XU 4. Therefore, 
the evaluation context R = main(v¥)| ]{€} is such that R = R[rdx]. Moreover, 
since e is the body of the main activity, from | agent G { Sns 8; Act} OK 
we have that rdx cannot be started(a), or failed(a), or completed(a). So, 
1. holds. 

By structural induction on non-blocked activities with some (non zero) 
subactivities. 

Let R’ = a(v)[Sr,---Sr,]{e} with n > 0. Since R’ is non-blocked there is 2, 
1 <i<n such that: 


(a) Sr; = a’(e)(e’, e”) for some a’, @, e’, e” , or 
(3) Sr; = a'(w)[Sr’]{e’} for some a’, w, e’, Sr’ and Sr; is not blocked. 


Consider case (a). 

If one of the expression in € = ej; --- €,y is not a value, say e;, from Lemma 1 
there is a unique evaluation context € and redex rdx such that e; = €[rdx]. 
If rdx is not started(a), or failed(a), or completed(a), let R be 


a(v)[Sri---Srj_1 a/(vEe;41---em)(e’,e”) Srizi---Srp|{e} 


we have that R’ = R[rdx], and 1. holds. 

If rdx is started(a), or failed(a), or completed(a), let P = a/(VE e;41---em)(e’, e”) 
and S = (| }), we have that R’ = S(a(¥)[Sr1---Sr;-1 Plrdx] Sri1---Srp]{e}]) 
and 1(a) holds. Note that rdx cannot be fail since by the typing rule for 
activities in Figure 5, parameters, persistency, and preconditions of sub- 
activities must be side effect free, and therefore cannot contain fail. 

Similar if the expressions in @ are values and e’ is not a value, or @ are values, 

e’ = tr, and e” is not a value. (By using the suitable evaluation context.) 

If the expressions in @ are values and e’ # tr, or e’ = tr, and e” is a value, 
with S = (/}) then 2. holds. 

Consider case (). 

If n = 0 and e’ is a value, with S = (/}) and 3. holds. If e’ is not a value, as 
before e’ = E[rdx]. Note that, rdx cannot be started(a), or failed(a), or 
completed(a) since by the typing rule for activities in Figure 5, the body of 
an activity may not contain such expressions. If rdx # fail define R to be 


a(v)[Sri---Sr;_1 a/(w)[]{E} Srigi---Srp]{e} 
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and we have that R’ = R[rdx], so 1. holds. 

In case rdx = fail define S = a(v)[Sri---Sri_1 (/]) Srigi---Srnj{e}. 
Therefore, R’ = S(/a/(w)[]{E[rdx]}]) and 1(b) holds. 

If n > 0 we can apply the inductive hypothesis to Sr; = a’(w) [Sr |{e’} and 
we have that: 


1’. there is R, and rdx such that Sr; = R[rdx], rdx € VU Ax. Moreover, 
(a) if rdx is started(a), or failed(a), or completed(a), then Sr; is 
S(a'(v')[Se! Plax] Sx°]{e"}) 


for some S, P, al, v!, Sr’, Sr’, and e!; 
(b) if rdx = fail then Sr; is S(a'(v')[ ]{E]rdx]}), for some S, €, 
al, vat 
or 
2’. Sr; = S(a!(w!)[Br’ a2(v!)(v,e!) Sx*]{e2}) for some for some S, a!, 
ane a 1 e!, and e? such that: v' = tr implies e! = v? 
for some v 
or 


3!. Sr; = S(al(w!)[Sr' a2(v")[]{v4} Sr7]{e!}) for some S, al, a?, w, v!, 
awl a2 1 1 
Sr ,Sr°,v',ande. 


=a al = 
ow, SK; Bey v 
2 


Consider case 1’. 
If rdx is not fail, or started(a), or failed(a), or completed(a), define 


R! = a(V) (Sry aeons SYrj—1 R STji41 2 Srn|{e} 


then R’ = R’|[rdx] and 1. holds. If instead rdx is either one of the four previ- 
ously mentioned redexes, define S’ = a(¥)[Sri---Srj;-1 S Srj41---Srp|{e}, 
and again 1. holds. 

For cases 2’ and 3! define S’ = a(¥)[Sr1---Srj_1 S Srj41---Srp|{e} and 
the corresponding results hold. 


Lemma 9 (Canonical Lemma) Let © = typeEnv(I; | --: | In), and 
“lk v: TING. 


1. if T = Sns, then v = o, and and for some, k, 1 < k < n, Ix is 
o= Cle ia 
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2. ifT =A, thenv =a, and and for some, k, 1<k <n, I, isa=(---)4; 
&. if T=Bool, thenv=tr, orv =fls; 


q.. af T =typeOf (c), then v = ¢. 


Proof: By case analysis on the typing rules. 


Lemma 10 (Non-blocked agent progress lemma) Let M = T; | -:- 
I,, be such that } M OK, and let I, (for some k € 1..n) be an agent instance 
not completed and not blocked inM. ThenM= MM’ for some M’. 


Proof: Let I, be y = (1¥,g,R)°. Let typeEnv(M) = ©. From | M OK we 
have that © | y = (1v,a,R)* ox. Therefore, © lk R OK IN G and for all 
o € 6 we have that (a) = Sns, i.e., there is j, 7 € 1..n, such that I; is 
= ag Phe, 

Since we are assuming a well-typed program, + agent G { Sns 8; Act} OK, 
from Lemma 8 we have that 


1. there is R, and rdx such that R = R[rdx], rdx € YU Ax. Moreover, 


(a) if rdx is started(a), or failed(a), or completed(a), then R = 
S(a'(¥)[Sr P[rdx] Sr']{e}), for some S, P, a’, ¥, Sr, Sr’, and 
e; 


(b) if rdx = fail then R = S(a’(¥)| |{E[rdx]})), for some S, E, a’, ¥; 
or 


2. R= S(a(w)[Sr a/(v)(v,e) Sr’]{e’}] for some for some S, a, a’, W, ¥, 
Sr, Sr, v, e, and e’ such that: v = tr implies e = v’ for some v’ 
or 


3. R= S(a(w)[Sr_a’(v)[]{v} Sr’]{e}] for some S, a, a’, W, ¥, Sr, Sr’, v, 
and e. 


Consider the three cases. 


1. By cases on the redex rdx € XU Ax. 
For most of the redexes the corresponding reduction rule does not have 
restrictions. We only analyze the ones that require the well-typedness 
of the configuration in order to reduce. 
If rdx = spawnG(v) from the fact that the program is well-typed, G 
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is a defined agent and it has a main activity, and, from the typing 
rule [TnewG] the number of actual parameters matches the one of the 
formal parameters of the main activity. Therefore, [AGN] is applicable. 
Note that, subject reduction ensure that also the types are matching. 
If rdx = make A(¥), from the fact that the program is well-typed, A is 
a defined artifact, and, from typing rule [TnewA] the number of actual 
parameters matches the number of fields and properties of the artifact. 
Therefore, [ART] is applicable. 

If rdx = .s, from typing rule [Tsns], we have that s € 8, say s = sj, 
and Sns 8 € G. Moroever, from y = (1V,7,R)° the ith sensor instance 
exists. Therefore, reduction rule [SNS] is applicable. 

If rdx = sense v :filter 1, from typing rule [Tperc], © lk v : Sns ING. 
Therefore, from Lemma 9, v = o, and for some, k, 1 < k <n, Ix is 
o = (1v)5. If 1 = 1, for some i, then rule [PER] is applicable. If 
not, since the agent is not blocked, either there are other expressions 
reducible or case 2. or 3. hold, and therefore the term would reduce. 
If rdx = use v2.0(¥) :sns vj, from typing rule [Top], © Ik vo: A IN G, 
and the operation o is defined in A and as as many formal parameters 
as the values in v. From Lemma 9, ve = a, and for some, k, 1 <k <n, 
I, is a= (---)4. Therefore, reduction rule [USE] is applicable. 

If rdx = focus(vi,v2) from typing rule [Tfocus], © IF vg : A IN G. 
From Lemma 9, vg = a, and for some, kj 1 < k < n, Ip is a = 
(.--)4. Therefore, reduction rule [FOC] is applicable. Similar for 
unfocus(vj, v2). 

If rdx = observe vj.p from typing rule [TpropA], © |F vy : A IN G, and 


p is a property defined in A. From Lemma 9, v; = a, and for some, 
k,1<k<n, Ip isa =(---)4. Therefore, reduction rule [GETA] is 
applicable. 


2. From ¥ Ik R OK IN G we have © It a’(¥)(v,e) OK IN G. Therefore, 
“lk v : Bool IN G, and 1) IF e: Bool IN G. From Lemma 9, v = fls 
or v= tr. If v = fls then rule [DISP] is applicable. If v = tr, then 
e =v’ for some v’. From Lemma 9 then e = fls or e = tr. In the 
first case rule [PREC] is applicable and in the second rule [SCH]. 


3. In this case rule [END-SA] is applicable. 
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Lemma 11 Let a = (f = V,p = W,7,01---Om)* be an artifact instance, 
and let SIF a= (f= Vp = wv 

artifact A{U f; V p; Op Step} ox. Then, for alli, 1 <i <m we have 
that 0; contains only (sub)expressions in Ex U Ex, identifiers in f or p, i.e., 
R does not contain variables, or (sensor) identifiers, or expressions in Eg; 


Proof: From ) lt a= (f =V¥,p =W,G,0)--+0.,)* OK we have that, for 
alli, 1<i<m, UlF O; OK IN A. Observe that the typing rules of Figure 4 
and 6 are such that only expressions in €, U €x are allowed in operations or 
steps. The rule for artifact creation, [ART] of Figure 8, does not generate 
any expression, and the reduction rules of Figure 11 replace expressions in 
E€, U €x with values. Finally the rules for state change of artifacts of Figure 
12 are such that only expressions in €, U €y and not containing variables are 
inserted in the artifact instance. 


Lemma 12 Let I be a eg v,p W,7,01,---O,)4, a non-idle ar- 
tifact instance, 1.e. m > 0, and let % lk I OK for some %, and + 
artifact A{U f; V p; Op Step} oK. Then 


1. there is O, and rdx € Xx, UX, such that I is a (f= Vp 
w,o,0 Olrdx])4. Moreover, if rdx 4 .f, and rdx #.p, I is 


a=(f=V,p=W,7,0 (c,0(¥)[St](tr){E[rdx]}))* 
for some ¥, 0, 0, St, E, or 


2lisa=(f=V,p=w,0,0 (,0(¥)[Sty---Stp](tr){v}))4, n> 0, for 
some V, 0, 0, St, or 


e, €, or 

4. lisa = (£ =%,p =W,7,0 (c,0[o(v)(f1s) o'(v)(tr) St]))* for 
some VW’, 0, 0, 0’, o(¥)(fls), 0, St, or 

5. lisa = (£ =¥,p =W,0,0 (0, 0[01(¥')(£1s) ---on(¥")(£1s)]))4 for 
some ¥, 0;,(1<i<n),o, 0 


Proof: Let I bea = (f =¥ ,G,01-+-Om)*, a non-idle artifact 
instance. Then I is a = (f =¥,p=W,a,0 0), where 0 is 


(a) (7, 0(v)[Sti ---Stp](e1){e2}), or 
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(b) (7, 0[o1(¥")(e1) +++ og(#4)(eq)]), p 2 0, and g > 1 


Consider case (a). 
Assume first that e; = v for some v. Since © lk I OK, from the typing rule 
for operations of Figure 14 we have that © lk v: Bool IN A. From Lemma 9, 
then v = tr or v = fls. If v = fls, then 3. holds. If v = tr and eg = v’ 
for some v’. Then 2. holds. Otherwise, from Lemma 1 there is a (unique) 
expression evaluation context, €, and redex, rdx, such that eg = €[rdx]. 
From Lemma 11 rdx € 4% U4. Define O to be (0, o(¥)[St1 ---Stp](tr){E}), 
1. holds. 

Assume that e; is not a value. From Lemma | there is a (unique) expression 
evaluation context, €, and redex, rdx, such that e; = €[rdx]. From Lemma 
11 rdx € Ax Uy. Define O to be (a, 0(¥) [Sti ---St,|(E){e2}). We have 
that OO[rdx]. From ¥ IF I OK we also have that rdx is side effect free and 
therefore may only be either .f, or .p. Therefore, 1. holds. 

Consider case (b). 

Let assume first (0, 0[01(¥!)(v1) --- 09(¥7)(v,)]). First, note that, since 
= IF I ok, from the typing rule for steps of Figure 14 we have that 
“lk vz: Bool IN A, 1 <i<q. From Lemma 9, then v; = tr or v; = fls. 
Therefore, either 4. or 5. holds (depending on the facts that the guards are 
all f1s or there is a tr and so a first one). 

Assume that (o, 0[01(7')(v1) ---0;(¥7)(e;) +++ 0g(¥7)(eq)]), and e; is the first 
guard which is not a value. From Lemma | there is a (unique) expression eval- 
uation context, €, and redex, rdx, such that e; = €[rdx]. From the previous 
point we can assume that all the vz, 1 < k < j—1 are such that vz, = fls. De- 
fine the evaluation context O to be (o, o[o(v)(fls) 0;(¥)(E) «+ - og(¥7)(eq)]). 
From the typing rule for steps of Figure 14 we have that rdx is side effect 
free and therefore may only be either .f, or .p. Therefore, 1. holds. 


Lemma 13 (Non-idle artifact progress lemma) Let} M OK, M= Ij 
--- | I, and (for some k € 1..n) I, is a non-idle artifact a = (f =V,p = 
W,7,01---On)*. ThenM=>M’ for some M. 


Proof: Let I, be a = (f =¥,p =W,G,0)---0,,)4. Let typeEnv(M) = ¥. 
From - M OK we have that © |F I, OK. Since we are assuming a well-typed 
program, | artifact A{U f; V p; Op Step} ok. From Lemma 11 we have 
that 


1. there is O, and rdx € Ax U X, such that I is a (f Vip 
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Li 


2. 
3. 


w,7,0 O[rdx])*. Moreover, if rdx A .f, and rdx £ .p, I is 


=¥,7,0 (c,0(v)[St](tr){€[rdx]}))4 


< iis @ = =V,p= w,7,0 (c,0(¥)[St1---St,](tr){v}))4, n > 0, for 


some V, 0, 0, St, or 


. lisa=(f=V¥,p=W,7,0 (0,0(¥)[St](fls){e}))4 for some ¥, o, 0, e, 


€, or 


. lisa=(f =V,p=W,a,0 (0,0[0(v)(f1s) o/(¥’)(tr) St]))4 for some 


, ot, or 


Lisa = (f ,0 me o[o1 (v1) (£1s) ---0,(¥")(f1s)]))4* for 


some V’, 0;,(1 


IN 
a 
IA Sl 
3 _ 
a a 


Consider the five cases. 


By cases on the redex rdx € XU Ax. 

If rdx = spawn G(v) or rdx = make A(v), is like the corresponding cases 
of Lemma 10. 

If rdx = .f, from the typing rule [TfieldR] of Figure 4 we have that 
f € f. Therefore, rule [GET] is applicable. 

If rdx = .p, from the typing rule [TpropR] of Figure 4 we have that 
p €p. Therefore, rule [GETPR] is applicable. 

For all the other redexes, 


a = (F=¥,p=%,2,0 (c,0(#)[St}(tr){E[rdx]}))" 


for some V, 0, 0, St, €. If rdx = .f = v, and rdx = .p = v, similar to 
the [GET] and [|GETPR] cases. 

If rdx = signal(1(v)), since the configuration is well-typed, from the 
rules in Figure 14 the sensors in @ and o are defined, therefore [GEN]is 
applicable. 

If rdx = next o(v), from the typing rule [Tnext] of Figure 4 we have 
that step o(U x)--- € A, therefore rule [NEXT] is applicable. 


If n > 0 rule [SELG] is applicable, and for n = 0 [END] is applicable. 
Rule [FLS] is applicable. 
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4. Rule [SGO] is applicable. 


5. Rule [SKIP] is applicable. 


Proof of Theorem 2 (Progress): 


By Lemmas 10 and 138. 
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